Interruptibility/priority control scheme for artificial intelligence software shell

ABSTRACT

An artificial intelligence software shell for plant operation simulation includes a blackboard module including a database having objects representing plant elements and concepts. A rule-based knowledge source module and a case-based knowledge source module, in communication with the blackboard module, operate on specific predefined blackboard objects. An input data module, in communication with the blackboard module, enables a user to input data to the shell. A control module, in communication with the knowledge source modules and the input data module, receives all input data and controls operation of the knowledge source modules in accordance with a predetermined knowledge source interruptibility/priority scheme. The control module including an event detector module having a hash table defined by a chaining algorithm.

RELATED APPLICATIONS

The present application relates to application Ser. No. 07/995,209,filed Dec. 22, 1992; application Ser. No. 07/994,668, filed Dec. 22,1992; and application Ser. No. 07/994,664, filed Dec. 22, 1992.

FIELD OF THE INVENTION

The present invention relates to an artificial intelligence softwaresystem for plant operation simulation and, more particularly, to aninterruptibility/priority control scheme for such a system.

BACKGROUND OF THE INVENTION

Factory and processing plant environments are so diverse that they aredifficult to describe in specific terms. Many difficulties areencountered in trying to understand plant operation in a general waybecause of this diversity. There do exist, however, in the field ofmanufacturing, some common operational characteristics that a factory orprocessing plant should possess for efficiency purposes. In particular,it has become increasingly desirable for a plant to be operated in anoptimal manner with respect to material resources, human resources andtime. Areas of focus, in this regard, include the utilization of soundengineering principals, economic planning and safety.

Simulation modules of plant operation, which incorporate specificknowledge of plant operation, aid in implementing such principals inpractice. Because of the complexity of most plant environments, however,experts such as manufacturing engineers only have knowledge limited tothe particular areas of the plant domain within which they work. Thisknowledge may exist in different forms ranging from analytical models toheuristics. Because of the incompatibility of the forms of knowledge, itis very difficult to incorporate the knowledge in a complete plantmodel.

The application of computer technology in the plant environment iscommonplace. In all areas of production, one can find computers used fora variety of tasks from control of equipment to data logging. Oneparticular area that is growing is the use of computers to implementknowledge-based systems, or expert systems, in the plant domain to aidin achieving plant operation efficiency. A knowledge-based systemcontains a representation of knowledge about some aspect of the plantoperation, and it provides diagnoses or recommendations by using someform of logical reasoning or heuristics to process the knowledge. Thesystems represent a distinct use of computers beyond numerically-basedapplications. Attempts have been made to create a knowledge-based systemwith which one can combine the power of the computer with the expertiseof plant operators to yield a tool that can assist in the operation ofthe plant, and provide diagnostic information that can be used tomonitor the plant and its resources. Because a plant may have manydifferent knowledge sources and expert systems, a method of integrationwould allow interaction among different systems and would permit broaderissues of plant operation to be incorporated within the computationframework. Because of the different forms of knowledge sources andexpert systems, such a method of integration has not been achieved tomodel complete plant operation. In addition, because every plant differssomewhat in specific areas, a system has not been realized whichpossesses functional modules in an overall structure sufficiently broadto be useful in diverse plant environments.

In order to achieve such a system, it is important to modelcharacteristics of every plant that are common. One such characteristiccommon to every plant is that in some complex way, inputs (rawmaterials) are processed to produce outputs (finished products). Anothercommon aspect is that all plants involve processing over time.Unfortunately, a complete analytical description of a plant involvingfull time dependencies is impractical, if not impossible. Informationconcerning a plant operation is typically incomplete and fragmentary.Abundant information relating to plant operation, however, may exist,but in order to create a system, it must be gathered and organized intosuch a system. This has not been done successfully in the past withknowledge-based systems.

Accordingly, a general object of the present invention is to provide aknowledge-based system which possesses functional modules in an overallstructure sufficiently broad to be useful in diverse plant environments.

Another object of the present invention is to provide a knowledge-basedsystem which can combine the power of the computer with expertise ofplant operators to yield a tool that can provide diagnostic informationand monitor operation of the plant.

Another object of the present invention is to provide a control processfor a knowledge-based system for controlling operation of the system inan efficient and orderly fashion.

SUMMARY OF THE INVENTION

To accomplish the foregoing and other objects, features and advantagesof the invention, there is provided an artificial intelligence softwareshell for plant operation simulation which includes a blackboard moduleincluding a database having objects representing plant elements andconcepts. At least one knowledge source module including an artificialintelligence operation scheme, in communication with the blackboardmodule, operates on specific predefined blackboard objects. An inputdata module, in communication with the blackboard module, enables a userto input data to the system. A control module, in communication with theinput data module and the at least one knowledge source module, receivesan input data and controls operation of the at least one knowledgesource in accordance with a predetermined knowledge sourceinterruptibility/priority scheme.

The control module includes an event detector module and anactivation/agenda manager module. The event detector module, incommunication with the input data module, receives all input data anddetermines when the at least one knowledge source should execute. Theactivation/agenda manager module, in communication with the at least oneknowledge source module and the event detector module, executes the atleast one knowledge source module in accordance with the predeterminedknowledge source interruptibility/priority scheme.

In a preferred embodiment of the present invention, the at least oneknowledge source module includes a rule-base knowledge source moduleand/or a case-based knowledge source module. The rule-based knowledgesource module has a forward-chaining belief propagation scheme includingrules in if-then-else form with associated levels of belief. Thecase-based knowledge source module has a data comparison schemeincluding predefined patterns and conditions, whereupon execution of thecase-based knowledge source, the conditions are inferred to be true if acertain level of closeness is found between the received data and thepatterns.

BRIEF DESCRIPTION OF THE DRAWINGS

Numerous other objects, features and advantages of the invention shouldnow become apparent to those skilled in the art upon a reading of thefollowing detailed description taken in conjunction with theaccompanying drawings, in which:

FIG. 1 is a block diagram of the overall system environment of thepresent invention;

FIG. 2 is a detailed block diagram of the overall system environment ofFIG. 1;

FIG. 3 is a block diagram of the blackboard architecture;

FIG. 4 is an overall system block diagram;

FIG. 5 is a block diagram of a blackboard data structure;

FIG. 6 is a list of value type codes for the blackboard;

FIG. 7 is a block diagram of event detector data structures;

FIG. 8 is a logic list of event detector software;

FIG. 9 is a list of activation/agenda manager logic flow;

FIG. 10 is a diagram of a rule network example;

FIG. 11 is a diagram of rule-based node structures;

FIG. 12 is a diagram of rule structures;

FIG. 13 is a diagram of rule structures;

FIG. 14 is a list of rule-based knowledge source logic flow

FIG. 15 is a list of formulas for combining evidence with rule belief;

FIG. 16 is a diagram of case-based knowledge source data structures;

FIG. 17 is a diagram of an input data structure;

FIG. 18 is a list of logic flow of user interface software;

FIG. 19 is a detailed system block diagram;

FIG. 20 is a list of data message type codes;

FIG. 21 is a list of control message type codes;

FIG. 22 is a list of message type codes;

FIG. 23 is a list of a particular message format;

FIG. 24 is a list of a particular message format;

FIG. 25 is a list of a particular message format;

FIG. 26 is a list of a particular message format;

FIG. 27 is a list of a system file format;

FIG. 28 is a list of a blackboard structure description file format;

FIG. 29A, 29B and 29C are a list of a rule-based description fileformat;

FIG. 30A and 30B are a list of a case-based description file format;

FIG. 31 is a list of an input data file format;

FIG. 32 is a list of a log file format;

FIG. 33 is a list of a diagnostic file format;

FIG. 34 is a list of a blackboard status file format; and

FIG. 35 is a block diagram of a blackboard control module

DETAILED DESCRIPTION I. Introduction

The present invention provides an artificial intelligence software shellin which a blackboard database includes objects representing plantitems. Expert system knowledge sources, in accordance with a temporalpriority scheme, execute and modify specific objects. A user can viewthe status of the objects to diagnose and monitor plant operation. Anapplication developer (plant expert for a particular application) mustdevelop the objects and knowledge-based rules before the system can beused. A control process, in accordance with the present invention,receives all input data, and determines when each knowledge sourceshould execute, in accordance with a predetermined knowledge sourceinterruptibility/priority scheme. Knowledge sources are prioritized andthe control process controls operation of the knowledge sources inaccordance with the priorities. For example, as will be described ingreater detail herein, the control process may interrupt execution of alower priority knowledge source in favor of executing a higher priorityknowledge source.

The domain shell can be described from two viewpoints. One way to lookat the domain shell's organization is from the knowledge-based systemfunctional view. For the domain shell this is a description of theblackboard architecture, its components and their interaction. This isthe internal view of the system. The other view is from the user'sstandpoint, that is, how does the system appear to the user as heinteracts with it or uses it. The details of the interfaces and theoperating sequences that occur are the external system view. While theserepresentations are different, they are strongly related to each other.

The overall system environment diagram is given in FIG. 1. The domainshell will consist of an environment in which a specific applicationprogram can be developed. This is known as the application developmentenvironment. It has the functions that are used by the applicationdeveloper to enter, modify and test the structure for the application.These structures form an instantiation of the blackboard approach,including a control framework. The knowledge sources are created andentered at this stage as well. The domain shell described in thisdocument will contain the tools and framework facilitating the creationof applications for any plant environment. An application developerwould benefit from the existence of structures common to his particularplant type. If structures representing equipment types and associatedicons were already features of the shell, the developer could use themwithout having to create them himself. The existence of such tools wouldalso have the benefit of standardizing the graphical appearance of therunning system. Clearly, there are types of plants (such as steel millsor food processing plants) which would benefit from having a set ofstructures that are specific to the plant type (such as icons of aroller press for the steel mill). As a first step, the developer couldcreate a steel mill domain shell by adding to the domain shell the setof structures that would be useful to the application developer in aparticular steel mill. Then the application developer in any steel millcould use the created structures, thus easing the burden of development.The increase in value of the plant type specific domain shell suggeststhat the level of customization of the domain shell be carefullyconsidered to maximize the shell's utility.

After the application development is completed and tested, it isinstalled on-line in the plant environment. The system then enters theapplication execution environment. Here the users are the plantpersonnel that interact with the system to receive the systemrecommendations and take appropriate action.

FIG. 2 is a more detailed view of the two environments. This shows thedistinctions in the two environments. Note that the knowledge-basedsystem framework resides in both environments. The link between thesetwo systems is the compiler, which translates the entered informationinto a format suitable for real-time operation. Note that the "compiler"is included as part of the App. Der. Env. The knowledge-based system inthe development environment is the system that is created by thedeveloper, represented in a form that allows easy editing, manipulatingand testing, while the knowledge-based system in the executionenvironment represents the runtime version of the system, having beenmodified for compactness and efficient execution. The domain shellspecified here can be described in detail by examining these twoenvironments.

The end users are the plant personnel who will use the system in thereal-time plant environment. This view of the system emphasizes thedetails of the interface to the users, and describes the features thatinclude the presentation of information, and the nature of the types ofinputs that the user might enter.

The domain shell's architecture will be visible to the end user mainlyin the manner of presentation of information. This includes the use of awindowing environment that allows the user access to different levelsand types of information. The window environment should be heldconsistent so that all users maintain familiarity with the mechanics ofoperation within all parts of a particular application and also acrossapplications.

The system will allow the end user to view the reasoning processes andto be provided with explanations of what the system is doing and why. Itis important to maintain the explanation at a simple level, so that theplant operator is not overwhelmed by too much information when facedwith the need to make a time-critical decision. However, the generalityof the shell will allow the application developer to alter the runtimecharacteristics to optimize the appearance for the specific application.

Another major aspect of the external view is the ability of the user todirect the system to focus attention to certain aspects of plantoperation. One example of this would be informing the system of aspectsof planning so that the monitoring system can appropriately adjust itsoperation. This would occur, for example, if the operator knew of ascheduled shutdown of a part of the plant operation. The applicationwill have the means of receiving this information and actingappropriately. Note that this type of action would have been"programmed" into the system during the application development phase.As implemented, it is only possible to specify this type of informationby developing an external process (to the shell) that receives and sendsblackboard data that specifies this type of information.

One final aspect of the external view is the presentation of conclusionsand recommendations produced by the system. Since these aretime-critical, appropriate methods of presentation will be used. Onceagain, the domain shell will provide a selection of presentationmethods; it will be the task of the application developer to choose theappropriate presentation.

After the application has been created for a particular plantenvironment, the system is then installed with appropriate interfacesestablished. The system is then set into operation in the runtimeenvironment. This will involve the blackboard framework in operationwith the contributing knowledge sources.

To facilitate the creation of an application, the domain shell willprovide a set of what could be considered programmer tools. Editors tocreate and modify the blackboard structures will be implemented. Theseeditors will guide the user in the development phase by ensuring thatthe structures are viable. Compilers will translate the informationentered by the developer into a form suitable for execution inreal-time. Development diagnostic tools, will give the developer a meansof checking the validity of his work before execution.

Because of the general nature of the domain shell, it is impossible tostate the exact sequential nature of operation. This will be determinedby the characteristics of the application as designed by its developer.

The internal view involves the description of the blackboard approach.This is the domain of the application developer, who must apply thetools in the domain shell to create the specific application. Theinternal structure is given in FIG. 3.

The blackboard structure contains data that is of relevance to one ormore knowledge sources. Basically, it is a structure representing thestate of the system. The developer creates a blackboard structure byorganizing a hierarchy of information slots at different levels. Simplyput, the highest level represents the broadest view of the plant, andeach level beneath is a successively more detailed representation of apart of the plant. Note that the structure as created in the developmentenvironment must be augmented by actual and simulated data that ismeasured or derived during runtime.

The hierarchy of the blackboard is basically a partitioning of theunderstanding of the plant on different levels. For the plantenvironment, the partition that is most evident is the spatial andstructural arrangement of equipment and processing areas in the factoryitself. One can see the plant on a very abstract level, where rawmaterials enter a building at one end and finished products emerge atthe other end. At lower levels, the processing can be seen to involve aseries of steps or subprocesses, each of which can be represented on theblackboard. On the blackboard, parameters and variables of interestwould be placed. These would be the parameters used by one or more ofthe knowledge sources.

The blackboard will hold this information. The domain shell will providethe blackboard structure components, and give the application developerthe means of creating a blackboard framework specific to the plant. Thisframework will represent a model of the plant as the system understandsit.

The knowledge sources are the particular segments which contain someform of reasoning about some part of the information in the model. Eachknowledge source has its own domain, that is, the parts of theblackboard that it has knowledge about. A knowledge source interactswith the blackboard by initially recognizing that it "sees" something onthe blackboard of interest. It then asks and receives permission toalter some other section of the blackboard based on conclusions that ithas reached. In this way, the state of the system (as seen on theblackboard) is updated and the overall system acts appropriately on theinformation in the blackboard. In the present application, however, thecontrol process does the recognizing.

Each knowledge source in the blackboard system is responsible forrecognizing the things that are important to it. In other words, eachsource should contain reasonable knowledge about its own domain ofinterest. In the domain shell, the application developer must have theinformation needed to integrate the knowledge sources into the system,and ensure that the knowledge source can interact with the blackboard.The knowledge source should provide the blackboard system with someindication of the urgency of its information.

The value of the blackboard approach is that different knowledge sourcescan apply their reasoning to overlapping parts of the blackboard. Whilethe ability to overlap knowledge source domains introduces complexity,it is more valuable because it allows knowledge sources to fail withouttotally crippling the system. All major engineering systems provide forsafety margins and backups, and the blackboard approach not only allowsit but in effect encourages it by making sure that information isavailable to the knowledge sources that need it.

The simulator is a collection of mathematical and functional tools thatcan be used by the system. These tools include algebraic, difference anddifferential manipulations. These tools are not implemented as adistinct entity, though these tools do exist in parts of the domainshell.

The control is perhaps the most critical part of the blackboardapproach. The control oversees the actual operation of the system. It isresponsible for determining which knowledge source should access theblackboard, as well as prioritizing the operations of the knowledgesources. This portion of the blackboard structure will require the mostthought, but will yield the most powerful performance if a well-designedcontrol is developed.

A critical portion of the application development process will bedetermining an appropriate control hierarchy for the different knowledgesources. Even if the knowledge sources don't interact (their domains aremutually exclusive), the real-time nature of the domain shell requiresthat the system recognize the most urgent request first. For a complexapplication, different knowledge sources may have relevant informationthat could conflict. Thus, while the domain shell described here willprovide a general set of tools for the application developer, it isvital that he develop a coherent problem solving strategy.

Because of the expected diversity of intended applications in the plantenvironment, the domain shell requires flexibility in knowledgerepresentation, as well as the capability to adjust operation to thespecific application. By use of the blackboard architecture, the desiredflexibility is achieved while maintaining a foundation of standardizedstructure that can be the basis for expansion.

Overall System Design Description

This section describes the design of the shell at the operational level.It briefly discusses the system design concept and gives the modulardecomposition of the shell. The system design is based on satisfying therequirements given elsewhere in this document.

A block diagram view of the domain shell is shown in FIG. 4. The systemis divided into the following modules: the blackboard, the eventdetector, the activation/agenda manager, the rule-based knowledgesource, the case-based knowledge source, and the user interface. Each ofthese modules represents a distinct UNIX process. Within the context ofa specific application, there will exist one blackboard process, oneevent detector process, one activation/agenda manager process, and oneuser interface process. In addition, there must be at least oneknowledge source process; multiple knowledge source processes arepermitted.

Prior to the use of the shell, the user creates all the required inputfiles. The required files are: the Blackboard Structure Description File(BSDF), one Rule-Base Description File (RBDF) for each rule baseknowledge source, one Case Description File (CDF) for each case basedknowledge source, and at least one Input Data File (IDF). The prototypesoftware does not have editors; the app. developer creates these filesoutside of the shell.

In one embodiment, the shell will internally generate any descriptionfiles.

While the shell checks the files for syntactical correctness, allowingthe user to correct errors through a text editor, the shell does notscan the files for higher level errors or inconsistencies. Therefore,the user must ensure that the files contain consistent information orelse the shell will generate unexpected results.

The shell is run by typing the program's name at the UNIX shell prompt,together with the system file name. The system (application) file nameidentifies a file that contains a list of files defining the structureof a particular application. The set of files determines the structureof the blackboard application; the BSDF and all RBDF's and CDF's relatedto the blackboard belong to the application. There is sufficientflexibility here to permit, for example, the creation of similarapplications with perhaps one knowledge source removed. This allows theevaluation of the usefulness of a particular knowledge source to theapplication being tested.

After the system file has been given to the shell, the shell then beginsloading the information. The shell starts the appropriate processes andsupplies them with the name(s) of the appropriate file(s). This wouldinclude the blackboard process, the event detector process, theactivation/agenda manager process, and the rule-based and case-basedknowledge source processes. After all of the input files have beenloaded, the shell is ready to initiate a session run of the application.In one embodiment, it asks the user to set the run parameters andspecify the Input Data File (IDF). In another embodiment, IDF's are notused in the run-time environment. At this point the session run begins.

A session run of an application consists of the shell receiving inputdata and taking appropriate action based on the data. The determinationof appropriate action is the responsibility of the event detectorprocess. Data values are updated on the blackboard and test conditionsare evaluated to determine whether a knowledge source should be fired.If a knowledge source should be fired, then its name is placed on aFirst-In-First-Out (FIFO) queue to await execution. The presentinvention uses more sophisticated control including interruptibility.

The activation/agenda manager controls the execution sequence of theknowledge sources. It ensures that only one knowledge source is executedat a time.

Each knowledge source process used by the application containsappropriate structures relevant to its domain of expertise. During theshell's operation, each knowledge source pauses until activated by theactivation/agenda manager. Upon awakening, the knowledge source executesits routines in an attempt to generate a diagnosis. When a knowledgesource makes a diagnosis, it is written into a diagnostics file.

As a knowledge source executes, it requests data from the blackboarddirectly. Thus, all knowledge sources have direct read privileges withthe blackboard. However, data updates to the blackboard generated by aknowledge source are directed through the event detector. The eventdetector can then scan the data to determine if an event has occurred.

The design decision to direct data updates through the event detector isan important one. The alternative is to allow each knowledge source towrite directly to the blackboard. The advantage of direct writing is theefficiency of writing to the blackboard. The disadvantage is that theevent detector must then continuously search the blackboard to determineif updated data is present. The shell's design, with indirect dataupdates from the knowledge sources, makes uniform all updates to theblackboard, whether from sensors or from knowledge sources.Conceptually, this is a simplification for the event detector, which hasother difficult tasks to perform. If the event detector had to searchthe blackboard continuously, it would represent a fundamental conceptualshift in the blackboard operation from an asynchronous, data-drivenprocess (as originally envisioned) to a mixed combination ofasynchronous processes and systematic searches.

The sequence of reading input data, firing knowledge sources andgenerating diagnoses continues until the user specifies to the shell tostop. At this point, an ordered list of the diagnoses, the DiagnosticsFile (DF), is generated.

Description of Processes

This section describes in more detail each of the processes involved inthe execution of the shell. Each process is described in terms of fourentities: a brief summary of its purpose, the process name, datastructures, and the logical flow of the program. The data structures andlogical flow entities are augmented by programming guidelines wherevernecessary. The input/output relationships are described hereinafter. Itshould be noted that the level of detail in this section is such as toguarantee proper operation of the overall software. Thus, programmersare constrained by the information contained here. For example, the datastructures described in subsequent sections are implemented as describedhere; programmers are free to use any other structures that also mightbe required for the proper operation of a module.

The Blackboard

The blackboard process incorporates the blackboard objects and themethods necessary to manipulate the objects. Process name: blackboardData structures: FIG. 5 shows the basic organization of the datastructures which represent the blackboard objects. The structure on theleft is an array which implements a hash table. On the right, linkedlists store the attribute/value pairs.

Programming guidelines:

The hash table is implemented using Brent's variation of the openaddressing with double hashing algorithm. The size of the hash tablestarts out at a large number, but not excessive. For example, 503. Ifthe number of objects causes the table loading factor to exceedapproximately 85%, a new, larger table is allocated, and the data isrehashed. The maximum hash table size is 43,391 or larger.

The hash table key is the object name, and the table entry is a pointerto an object structure, which also contains the name of the object(pointer to a string). Upon retrieval, the key and the name string arealways compared. Accessing an object/attribute is also possible by usingthe index of the object in the hash array, and the index of theattribute in the list. This provides a fast access mechanism duringruntime, if such indices are known by the entities requesting theaccess.

Attribute structures include a demon slot, optionally referencing afunction. If present, the function is executed each time the attributereceives new value(s).

Value structures contain a "type" slot. FIG. 6 shows the type codes.

Value structures contain a "time stamp" slot, in seconds. Insertion inthe list is such that most recent values are first.

Insertion in the value list is done such that there is always one, andonly one value older than current the time stamp minus the historylength. All other, older values are discarded.

Logic flow:

The blackboard manager performs several functions. First, after theprocess is started, it creates the blackboard structures frominformation contained in the file whose name is passed on to it. Then,it receives messages which request getting or putting data on theblackboard. Each message is acknowledged by one of the following: a datamessage, if a successful "get" took place, an ACK message, if asuccessful "put" took place, or a NACK message, if an error is found. ASTOP message from the user interface tells the software to write out theblackboard structures and exit. A RESET message causes the blackboard toclear all its data contents, but not its structure ofobjects/attributes. This module can be written in a structuredprogramming language such as ANSI C.

The Event Detector

This process receives data from external sources. It also receives thedata that knowledge sources want to write on the blackboard. Allincoming data is sent to the blackboard process. Every piece of incomingdata is also checked for potential detection of an event. An event maybe triggered by the value of data, i.e., by satisfying an expression, orby the simple arrival of a data point, regardless of its value. Timerbased events are handled by the activation/agenda manager process. Alist of knowledge sources associated with detected events is sent to theactivation/agenda manager process.

Process name: event detector

Data structures: FIG. 7 shows the data structures required by thisprocess. On the left, an array implements a hash table. Each datasource, be it sensor (external) data, or knowledge source generated, hasan entry in the hash table, which points to a data point structure. Eachdata point then has an associated indirect expression list. The elementsof this list point to entries in the expression list, which in turn, haspointers to the expression arrays.

Programming guidelines:

The hash table is implemented using a simple, double hashing algorithm.Since the event detector is a potential bottle neck, the highestpossible performance should be sought.

The size of the hash table is expected to be smaller than the blackboardtable. It also starts at 503, and more space is allocated if the loadingfactor exceeds 90%.

The hash table key is the concatenation of the object and attributenames. The table entries point to data structures which also contain theobject/attribute names. The names are always compared during retrieval.

Logic flow: FIG. 8 shows a simplified representation of the program'slogic. The initialize part is executed when the process is started: itcreates the structures shown in FIG. 7, by loading and parsing the eventexpression definitions from the knowledge source description files whosenames are passed to it as arguments. The remainder of the program isdriven by the receiving of messages.

Programming guidelines:

All incoming data messages are acknowledged by a NACK message if asyntax error is found, or by forwarding the blackboard acknowledgmentmessage back to the original sender otherwise.

An expression evaluator is described herein. Event defining expressionsare similar to evidence expressions, hence the same software is used.

The operators used in expressions are essentially the same as operatorsused elsewhere in the system. Thus, in order to differentiate betweennewly arrived values, and older values, available from the blackboard,the new operator is required to precede object/attributes which triggeron arrival of new data.

If there are no expressions associated with a knowledge source, suchknowledge source will only fire if one of its preconditions include theevery operator. This module can be written in C++, since it hasobject-oriented features.

The Activation/Agenda Manager

This process starts the execution of a knowledge source. The knowledgesources activated by the event detector are started immediately, if andonly if their preconditions evaluate to TRUE. If no preconditions aredefined for a knowledge source, it will fire at the next opportunity. Apriority scheme determines execution order. A separate queue is kept forknowledge sources that execute periodically.

Process name: a manager

Data structures: There are three basic data structures required by thisprocess: (a priority scheme for activation of event driven knowledgesources), a time-based queue for periodic knowledge sources, and aknowledge source/precondition expression structure for checkingpreconditions. The latter is conceptually identical to the eventdetector data structures, as shown in FIG. 7, with the followingdifferences: a hash table is not required at this time, a simple arrayof size 100 will suffice; an expression list for each knowledge sourceis pointed to by the array elements; hence, the object/attributestructures and the indirect expression lists are not needed; the"knowledge source" and "updated" slots in the expression list structuresare also not needed.

Logic flow: Although it is basically one process, the software thatimplements the activation/agenda manager is best thought of as twointerrupt driven programs. One reacts to the arrival of a message fromthe event detector, as shown at the top of FIG. 9. The other reacts tothe passing of time, as shown at the bottom of FIG. 9.

Programming note: Although this process is best thought of as twointerrupt driven programs, the actual implementation approach is at theimplementer's discretion. This module can be written in C++.

Rule Based Knowledge Sources

This process implements a basic data-driven (forward chaining) inferencemechanism operating on a set of IF . . . THEN . . . rules, withpropagation of belief.

Process name: rule based/Data structures: The basic data structure isthe rule network (tree). An example is shown in FIG. 10. The networknodes exist in three fundamental layers: the input layer, consisting ofdata nodes, the intermediate layer, consisting of hypothesis, variableand constant nodes, and the output layer, consisting of malfunctionnodes. Their structures are shown in FIG. 11. The data and malfunctionnodes must have blackboard equivalents. The other node types(hypotheses, variables and constants) may, but are not required to. Thesupporting- and supported-rules slots contain pointers to structureswhich describe the way nodes are inter-related. These structures are therules, and their basic organization is shown in FIG. 12. Also shown inthis figure is the structure of meta-rules.

In addition to these structures, FIG. 13 shows the organization ofseveral other entities which are required for the implementation of thefeatures described in the functional specification. Some of these arefurther discussed. Lastly, a structure is needed to store evidenceexpressions.

Logic flow: The program first reads the rule base description file andcreates the structures described above. Then, it waits for a message. Ifit is a SETPARAM type message, then the program sets or resets thetrace, log and step run parameter, or it changes the value of the globalsufficiency and necessity factors, or it changes the values of theglobal alpha and beta cutoffs. For setting breakpoints, the rule basedknowledge source's own user interface is invoked. If the message is aRESET type message, then the program resets itself, in preparation for anew session run. If the message is an ACTIV type message, the programgenerally follows the steps shown in FIG. 14. The logical flow shown inthis figure is greatly simplified. Critical aspects of the software arefurther elaborated in the following sections.

Evidence Expressions

As shown in FIG. 14, before a rule can fire, certain conditions must bemet:

1. The rule's context must evaluate to TRUE,

2. The rule's evidence is available, and

3. The value of the evidence contribution towards the rule's hypothesismust be within the range defined by the alpha and beta cutoff values.

These conditions are dependent on expression evaluation. The generalstrategy for handling expressions is as follows. An expression isinitially specified in a rule base description file using a prefix orinfix notation. A few examples:

"if the temperature went from below to above 500 degrees in the pasthour":

    ((time-when (temp>500))<3600)

"if the change in pressure over the last 2 hours was less than 0.5":

    (<(trend pres 7200)0.5)

"if hypothesis #1 is TRUE AND at least one of the following is TRUE:hypothesis #2 is TRUE OR hypothesis #3 is TRUE OR hypothesis #4 isFALSE": (hyp1 and (or hyp2 hyp3 (not hyp4)))

The text is stored as a string in the evidence-text slot of the rule,for simple display purposes. It is also parsed into an expression-array.The structure of this array is a strict prefix, recursive representationof the expression, where the operators have been replaced by theircorresponding tokens (or pointers to functions), and the operands arereplaced with pointers to the structures holding the dynamic values, orwith the values themselves, if they are static constants.

In the last example, the numbers 2 and 3 indicate the number of operandsfollowing the token. A pointer to this array is placed in theevidence-expression slot of the rule. The parser also generates aseparate evidence-list containing only the operands which are pointers.This list is used for quick checking of the availability of theevidence.

Runtime evaluation of the expression then consists of recursivelycalling a simple evaluation function which performs the actualcalculation.

The conditions for firing a rule are then checked as follows:

1. Evaluate the rule's context expression. If TRUE (i.e., valueevaluates to 1),

2. Check if ALL the evidence components on the evidence-list have beenupdated. If yes,

3. Evaluate the rule's evidence expression. This returns a confidencelevel, CF evidence. This value, combined with the rule's sufficiency ornecessity (as described in the next section) determine the rule'scontribution to the belief in the rule's hypothesis. If the contributionaffects the hypothesis MB, and the contribution amount (value) isgreater than the alpha cutoff value, OR if it affects the hypothesis MD,and the contribution amount is less than the beta cutoff value, then therule can fire.

Operands can be of several types:

Value operands evaluate to a number. Value operands can be specified byan actual number, the name of a node, the name of a context, or anexpression which itself evaluates to a value. If a name is used, thenthe value used in calculations depends on the type of structure:

--hypothesis and malfunction nodes supply their CF slot value

--data, variable and constant nodes, and contexts supply the contents oftheir value slot.

CF operands are like value operands, except that the value must be anumber between -1.0 and +1.0.

Piece-wise-linear operands are the name of a piece-wise-linearstructure, which supplies a list of X-Y pairs for data interpolation.

Operators are also of various types:

Algebraic operators always return numerical values, and all of theirarguments are values. A list of these operators is given elsewhere. Inaddition a current₋₋ time operator is provided, which returns the timestamp of the current set of data.

Boolean operators always return a CF value. Their operand types howeverdiffer:

--fuzzy booleans (and, or, not) require CF type operands.

--weighted booleans (weighted-and, weighted-or) require (weight, CF)pairs, where the weight is a number.

--comparative booleans (equal, less, greater) take two value arguments,and an optional piece-wise-linear. If the latter is not specified, theoperators return +1 or -1 (TRUE or FALSE). Otherwise, a fuzzy result iscalculated by mapping the difference of the two numeric arguments on thex-axis of the piece-wise linear function, and returning thecorresponding y-axis value.

Time-based operators always return a numerical value. Their operands area node name and a value (delta T). The second argument must be an actualnumerical value. A list of time based operators is given elsewhere. Inaddition, two more operators are added: a time value operator, whichreturns a value from the node's history, and a time stamp operator,which returns the time stamp of a data node (not necessarily the same ascurrent time).

Change-based operators always return a value. The time when operatorrequires one expression as an argument. When the truth value of theexpression goes from FALSE (less than zero) to TRUE (positive value),the time of the transition is recorded. Hence, the expression should bea CF type. The value when operator takes two arguments: a CF expressionand a node name. When the expression goes from FALSE to TRUE, the valueof the node is remembered. Both of these operators accept an additionalargument, used to define the transition from FALSE to TRUE. If thisoptional argument is missing, the boundary between TRUE and FALSE is theglobal alpha cutoff value.

Other notes:

When expressions are used as a rule's evidence, they must evaluate to aCF type. In other words, the top level operators must be of booleantype. In all other circumstances (such as meta-rules and calculationsstored in variable nodes) there are no restrictions.

All node references in expressions which include time based operatorsmust have corresponding object/attribute entities in the blackboard,where the actual histories are kept. When the reference is in a rule'sevidence, then the name of the node should be used; when it is in anevent or precondition definition, the object/attribute names have to beused.

Only one change-based operator is allowed per rule.

All time references are in seconds. All time intervals are measured fromthe current time stamp (not necessarily the same as the current realtime).

Some operators have "aliases": add +; and &; diff -; div /; equal =;greater >; less <; not !; or ?; and times *. These operators can be used(either their names, or their aliases) in both infix or prefix notation.All other operators can be used in prefix notation only.

The number of arguments is generally implied by the nature of theoperator. Some operators however can take any number of operands: and,or, average, diff, div, max, min, std-dev and times.

Inference Mechanism

Propagation of belief. This is done in three steps:

1. Evaluation of a rule's evidence. This has been discussed in theprevious section. Also, see elsewhere, for combining formulas of booleanevidence.

2. Calculating the rule's contribution. Rules have a priori definedconfidence levels, named sufficiency and necessity (SF and NF). Thetable in FIG. 15 gives the complete algorithm. Note: this contributionis used in the determination of the alpha-beta cutoff.

3. Updating a hypothesis' belief. When more than one rule affects ahypothesis, the union probability rule is used:

    Beliefi=Belief.sub.i-1 +Belief.sub.rule-i -Belief.sub.i-1 *

Beliefrule-i, where Beliefi is the hypothesis' MB or MD, as indicated inFIG. 15, and Beliefrule-i is the contribution of the with rule, asindicated in FIG. 15.

Data nodes. The input into the system is in the value slot of the datanodes. These values are generally converted to beliefs by use ofcomparative booleans.

Meta-rules. These rules do not propagate belief, but are used to changethe context and to modify the importance of rules. The target-list slotof a meta-rule (see FIG. 12) therefore points to context or rulestructures. In the first case, the target-slot slot of the meta-rule isassumed to be the value slot of the context structure; in the secondcase, the SF or NF slots of the target rule must be specified. Thesource slot of a meta rule contains an expression. The value obtained byits evaluation is passed on as an argument to the optional function slot(a piece-wise-linear function), and the result is placed in thetarget-slot of the target contexts or rules. If a function slot is notdefined, then the result of evaluating the expression is placed directlyin the destination (target-slot).

When a meta-rule changes the context, all the rules that have alreadyfired, and whose context changed, are "unfired" (i.e., their effects areremoved). The program then re-checks rules that couldn't fire before thecontext change, for the possibility that they are in context now.Similarly, when a meta-rule changes the SF or NF of a rule, all effectsof this rule must be undone, and the rule fired again.

Two observations about meta-rules: first, they can cause infinite loops,due to the un-firing and re-firing process. Thus, each meta-rule has anoptional associated counter, which only allows a predefined number ofexecutions of the meta-rule. If a counter is not defined, it is assumedto be 1. Second observation: meta-rules must be used with caution, sincethey not only are difficult to use conceptually, but they also greatlyreduce runtime performance.

Evaluators. Although similar to rules, the purpose of the evaluators isnot to propagate belief, but rather to perform calculations. Thus, anevaluator structure (FIG. 13), has a context expression, just like arule. It's expression slot is evaluated, just like a rule's evidence.The result of this evaluation is then placed in the value slot of thevariable whose name is in the variable slot.

Debugging. Eight run parameters can be set:

trace: when set, it causes a detailed descriptive message to bedisplayed on the screen by each rule, when it fires.

log: exactly like trace, but output goes to a file with the extension".log"

step: when set, the program stops after each rule firing, and continuesonly when requested by the user

breakpoints: associated with rules, they cause the program to stop justafter the marked rule fired global SF and NF: they define default valuesfor these two parameters (i.e., if a rule is defined without an SFand/or NF value, then the global defaults are used.)

global ALPHA and BETA: they define default values for these twoparameters (i.e., if a rule is defined without an ALPHA and/or BETAvalue, then the global defaults are used.) The global ALPHA is also usedto define the default transition from FALSE to TRUE for change-basedoperators, if not specified within the expression.

All these parameters, except for breakpoints, can be set and cleared bySETPARAM messages from the user interface. The breakpoints are set bythe rule-based knowledge source software, via its own user interface:

User interface. The program's own user interface is invoked in one oftwo circumstances: when the user wants to set breakpoints, and duringruntime, if the step parameter is set, or a breakpoint is encountered.The program's user interface allows the user to perform a minimum amountof browsing through the rule base (e.g., list structures). The systemstructure shown in FIG. 13 stores the appropriate bookkeepinginformation for this purpose.

Output. Besides the log files, the program writes a diagnostic file,where the top malfunctions are listed. This output file has theextension ".out"

Actions. Several actions for the right hand side of a rule are provided:

Put value in bb. This action takes one argument, a node name. If therule having this action fires, the value of the node argument will besent to the blackboard. Note that a malfunction's value is sent to theblackboard automatically.

Assign. This action takes two arguments, first a variable name, second,a node name. The value of the second argument is placed in the valueslot of the variable node.

Show. This action takes no arguments. When the rule fires, informationsimilar to that displayed by the trace parameter is shown on the screen.This action is useful if a rule needs to be monitored, but withoutstopping the run (as a breakpoint would do), and without displayinginformation about other parts of the rule base.

Performance. The program will record its starting and stopping times, aswell as the number of rules fired and unfired. Blackboard access timesare also recorded. This module can be written in C++.

Case Based Knowledge Sources

This process calculates a similarity value for each case stored in itscase tables, by comparing each case with the current data.

Process name: case based

Data structures: FIG. 16, shows the information that is represented in acase table. The case-based process represents the data in the table intwo separate structures, as shown in FIG. 16: a static data array, and adynamic data array, for the time-dependent data. The static data arrayis simply an array of floating point numbers (doubles). The dynamic dataarray is an array of pointers, where each cell points to a historyarray. Each cell of the history array, in turn, contains a value/timepair. In addition to the data arrays, two other structures are needed,to store the function/weight information. One such structure correspondsto the static data array, and it is itself an array of function/weightpairs. The other structure corresponds to the dynamic data array, and itconsists of weight/pointer pairs. The weights are used for the result ofmatching the time dependent data; the pointers point to another array,which consists of function/weight pairs. In addition to these structure,a summary array is used to keep the final score of each case, togetherwith the name and attribute of the blackboard object to which the casecorresponds, and a description of the case.

Logic flow: The program has two parts. First the structures describedabove are initialized (loaded) from a case description file. Then,whenever the process is activated, the current data is compared to thedata in the structures, and scored according to formulas.

Programming guidelines:

There are four functions f used for scoring: equal, less than, greaterthan and match-points-on-curve. The latter function translates intoequals and weights of 1 in the function/weight array. Since all valuesare floating point numbers (doubles), the equal function is defined tobe TRUE whenever the two values are within some small percentage of eachother (e.g., 1%). This is true in all similar cases.

The results of applying the functions range from 0 to 1. Interpolationis performed between user defined points.

Aside from all of the above, a criterion is needed for when to place asimilarity score back on the blackboard. For example, whenever the scoreis greater than a predefined percentage of the maximum possible scorefor a case. The maximum score would then be calculated once, and storedin the summary array. In this implementation, the scores are alwayswritten back into the blackboard.

An output file is written at the end of each activation session, asdescribed elsewhere.

The User Interface

This module generally performs two functions essential to the operationof the software. It is the principal means by which the user interactswith the system. It also acts as a "supplier" of data during theexecution of the diagnostics.

Process name: user int

Data structures: FIG. 17 shows a general data structure that could beused to store the input data. This linked list is created from thecontents of one data file, and it is used to supply the data to theevent detector at the appropriate times, as determined by the time tags.Note that, at this time, the data values are of one type only (double);other data types may have to be added in the future. The use of thisstructure is optional.

Logic flow: FIG. 18 illustrates the sequence of operations that makes upthis program. There are three parts to this process.

First, the names of files in which the descriptions of the blackboardand of the knowledge sources are determined. The names of these filesare kept in a system file, which has the name <system name>.SYS. Thename of this file can be passed as an argument to the program:

    user int <system name>.sys

Next, the other processes are started. First, the blackboard process,then the control processes (event detector and activation/agendamanager), followed by the knowledge sources.

After the system has been loaded, the actual execution of thediagnostics is started. First the user has the option to set runparameters: tracing, logging, stepping and breakpoints can be set orturned off; SF's, NF's, alpha and beta values can be set. Then the useris asked for the name of a data file. At this point the user may, ingeneral, specify a time scale factor, which is used to "compress" or"expand" the time scale, such that data sets are run faster or slowerthan real time. The data sets are then supplied to the event detector,one at a time, until there are no more sets. The setting of the runparameters and and the execution of the diagnostics is then repeated aslong as the user wants to.

Programming guidelines:

After starting a process, the user interface waits until the processacknowledges the correct loading of its file(s). If an error occurs, aNACK message is expected. This message includes an error message, whichis displayed. In this case, the user has the option to repeat loadingthe file with the error, after it is fixed in a different UNIX shell.

The displaying of error messages due to syntax problems in files is theresponsibility of both the loading process and of the user interface.The setting of the trace, log and step run parameters is done from theuser interface, via messages to the knowledge source(s). The setting ofbreakpoints however, requires passing control over to a rule-basedknowledge source.

Before asking the user for a time compression factor, the program maydisplay the time required to run the diagnostics in real time, based onthe difference between the last and the first time stamps in the datafile. The time compression must be done such that the data sets do notbecome overlapping as the interval between them becomes smaller than theavailable time resolution.

Interface Description

This section provides the details of the interfaces between the modules.It also contains message format descriptions and file syntax structurefor the shell's input and output files.

FIG. 19 is a detailed picture of the system block diagram. It shows thesocket connections the message paths and the I/O files (Section 4.3)that are required for the shell. The man-machine interface and itsconnections are not shown in FIG. 19. However, its interfacerequirements are described in this section. Message queues are also usedfor communications. Message queues are a standard feature of the UNIXoperating system on HP computers. The manner of usage is similar to thatfor sockets; in other words, the description given here forcommunications applies also to message queues.

Communications

Interprocess communication between modules in the shell is based oneither the use of Berkeley Interprocess Communication (BSD IPC) Socketsor UNIX message queues. Either of these modes provides a means ofmessage passing so that data can be transferred between two processes.

The socket mechanism provides a related series of operations throughInternet domain sockets. Compatibility between the two domains exists ona function to function basis.

For socket communications, the shell uses stream sockets since theseprovide reliable, two-way communication. Communication through thechannel is analogous to that for UNIX pipes (file streams). The shelluses the sockets to exchange messages in a message sequence. The messagesequence is essentially a request-response pair. The initiating processrequests an action; the receiver then responds with either the resultsof the action, an acknowledgment of success, or a notification offailure.

Throughout this section it is assumed that the request messages are freefrom errors. However, processes will respond to an error in a messagewith a notification of failure (NACK) message if they are able to detectthe error before a response is needed.

For the shell, all required communication channels are establishedbefore a session run begins. When the shell is started, each of the sixprocess types described elsewhere is started (user interface,blackboard, event detector, activation/agenda manager, prototype only,and rule based knowledge source and/or case based knowledge source). Asequence of communication establishment then begins.

For socket communications, in its initialization, the user interfaceprocess establishes a bound socket with a listen queue. When the eventdetector, blackboard, activation/agenda manager and processes arestarted, they each request a connection with the user interface. Threechannels are established in this manner. The blackboard, event detectorand activation/agenda manager each establish their own bound socketswith a listen queue. Four additional channels are established: the eventdetector--blackboard channel, the event detector--activation/agendamanager channel, the activation/agenda manager--blackboard channel, andthe blackboard--man-machine interface channel.

Additional channels are established as the application's knowledgesources are spawned from the parent knowledge source process. For eachknowledge source, communications are established with the eventdetector, the blackboard and the activation/agenda manager.

There are two distinct uses of the connection within the shell. Thefirst use is data-oriented, being involved in requesting and supplyingapplication data for transfer between modules. The second use iscontrol-oriented. This entails the activation of processes and changesin the modes of process operation. However, the type of communicationestablished is independent of the use. Activities of either type of useare permitted. The content of the message determines the usage. Thedistinction is made in this document to efficiently categorize thedesign information presented herein. Only one communications channelnormally uses both data-oriented and control-oriented message sequences.This is the event detector--user interface channel. The data-relatedcommunication channels carry five distinct message types. They are shownin FIG. 20. The syntactical format of the message streams correspondingto these five message types are described hereinafter.

A further distinction of the DATASUP message type is possible betweendata headed for the blackboard and data coming from the blackboard. Thisdistinction can be made on contextual information (i.e. which process issending the data). However, it is not necessary to have a distinctmessage format specified, since the content of the message is similarfor both DATASUP messages. This socket channel is established as part ofthe initialization of the shell processes prior to a session run.

One task of the user interface is to supply the data input to the eventdetector. Data is supplied to the domain shell either from an input datafile, used to simulate "real" data, or a unix process external to theshell that sends "real" data. The event detector responds to the messagein one of two ways. If a syntax error is found, then the event detectorreturns a NACK message. Otherwise, the event detector relays the DATASUPmessage to the blackboard. This channel also carries control-orientedmessages. These messages are discussed herein.

The event-detector agenda/activation manager channel is established whenthe event detector and agenda/activation manager are initializing. Theconnection must be established prior to the beginning of the applicationsession run (when the input data is read).

The channel is used to deliver the list of knowledge sources to beactivated from the event detector to the activation/agenda manager. Theevent detector passes a KSSUP message that contains the list ofknowledge sources. The agenda/activation manager responds with an ACKmessage to indicate that a correct message was received. The eventdetector blackboard socket channel is established when the eventdetector and the blackboard are initializing. The connection must beestablished prior to the beginning of the application session run.

The channel delivers the data updates to the blackboard, and alsoprovides a two-way channel for the event detector to request data fromthe blackboard, and the blackboard to deliver the data. There are twomessage sequences that pass through this channel. One message sequenceis the event detector furnishing data to be updated on the blackboardwith a DATASUP message. The blackboard will acknowledge receipt of acorrect DATASUP message with an ACK. The other message sequence is thatof the event detector requesting data from the blackboard with aDATAREQ, and the blackboard supplying the data with a DATASUP.

The activation/agenda manager-blackboard channel functions in anidentical manner to the event detector--blackboard connection, exceptthat there is only one message sequence. This is the DATAREQ--DATASUPsequence as described in the previous section. The implementationrequirements for this channel are identical to those for the eventdetector--blackboard. See the previous section for details.

One channel is established for each knowledge source in the application.At this point, the required number of knowledge source processes isknown by the shell. When each spawned knowledge source process is beinginitialized, it requests a connection with the blackboard.

One message sequence type is used on the knowledge source--blackboardchannel. This is the DATAREQ--DATASUP sequence as described for theevent detector--blackboard channel. Here, the knowledge source is therequester of the data, and the blackboard is the supplier of the data.

Each knowledge source has a connection with the event detector. Theconnection is established when the knowledge source is beinginitialized.

The message sequence on this channel is the DATASUP--ACK sequence asdescribed for the event detector--user interface channel. The eventdetector responds to the DATASUP message from the knowledge source bysending an ACK message to the data-supplying knowledge source.

The shell uses a process starter that is responsible for starting andterminating the other shell processes.

There are six control-oriented message types. They are shown is FIG. 21.

The syntactical formats of the message streams corresponding to thesemessage types are described herein.

The event detector process starter channel is established during theinitialization of the shell processes prior to an application sessionrun.

The process starter is responsible for controlling the event detectorprocess. The process starter sends an appropriate control message to theevent detector. The event detector responds with an ACK message if themessage is correct.

The process starter a/a manager channel is established during theinitialization of the shell processes prior to an application sessionrun.

As in the previous section, the process starter a/a manager channel isused by the user interface to communicate appropriate control messagesto the activation/agenda manager.

The process starter blackboard socket channel is established during theinitialization of the shell processes prior to an application sessionrun.

Again, this channel is used by the user interface for controlling theblackboard as described for the user interface--event detector channel.

The process starter knowledge source channel is established when theknowledge source is initializing after it has been spawned.

The process starter must be able to shut down a knowledge source processwhen desired with a STOP message. This is one use of the channel.Another use is when the user desires to set operating parameters for aknowledge source. The user interface then sends a SETPARAM message tothe knowledge source, communicating the desired operating mode.

The a/a manager knowledge source channel is established when theknowledge source is initializing after it has been spawned.

The purpose of this channel is to allow the activation/agenda manager toactivate a knowledge source when it is time for that knowledge source tobegin reasoning. It sends an ACTIV message to the appropriate knowledgesource to inform it that it should begin active operation to produce adiagnosis.

A control message is also sent from the knowledge source to theactivation/agenda manager when the knowledge source has completedexecuting. This allows the agenda manager to update the status recordfor the knowledge source.

Messages

There are nine distinct messages that pass through the communicationpaths. All messages are headed by an integer code, which identifies thetype of message that follows. FIG. 22 shows a typical integer code foreach message. Actual implementation codes include additional informationto source and destination process.

The whitespace characters shown in the figures for the message formatsare present for clarity. The actual data message formats include thesize of the message and should also be efficiently aligned.

DATAREQ

This message contains a sequence of object attributes whose values arerequested. FIG. 23 shows the message format. The message begins with theDATAREQ identifier, followed by the number of objects whose attributedata is requested. Each object name and attribute name is then listed.

DATASUP

This message contains a sequence of object attributes with values andtime stamps for the attributes. FIG. 24 shows the message format. Theformat is similar to that of the DATAREQ message except that theattribute values and times are also present.

KSSUP

This message contains a sequence of knowledge source identifiers to beactivated. It is headed by the KSSUP identifier. FIG. 25 shows themessage format. The message is headed with the KSSUP identifier,followed by a sequence of knowledge source identifiers. The knowledgesource identifier is a unique handle for the application, determined bythe order of appearance of the knowledge source file name in the thesystem file. Note that UNIX process numbers are not recommended ashandles.

ACK

This message consists solely of ACK identifier code returned to thecommunication initiating process.

NACK

This message consists of an integer KNACk identifier code.

START

This message consists of a START identifier, followed by a characterstring. The character string provides the means of passing informationto another process. If the processing sending the string is ready tostart, then it sends the strink "OK" to the user interface. Otherwise,it should send an error message, to be displayed by the user interface.

STOP

This message consists of a STOP identifier.

ACTIV

This message consists of a ACTIV identifier.

SETPARAM

This message consists of a SETPARAM identifier, followed by a list ofarguments (character string). The arguments will specify to thereceiving process what particular parameter setting action to take. FIG.23 shows the structure of the message. There are six types of parametercodes. They are: trace, log, step, breakpoint, alpha/beta and sf/nf.Trace, log and step are followed in the message with a status code.Alpha/beta and sf/nf are followed by two numbers representing floatsthat are the first and second parameter values. Breakpoint requires theuser to interact with the receiving process to set breakpoints.

Input/Output Files

All files used by the shell are identified by type by the use of aparticular suffix. The filename is filename.suffix, where filename is adescriptive name supplied by the application developer, and suffixidentifies the file type. Suffix identifiers are specified in theappropriate sections below. In general, suffixes can be in lower orupper case.

Input files are created outside of the shell, then supplied to the shellthrough specification of a system file.

The application development editors automatically create these files;the developer need not edit them outside the shell, and in fact maycompromise the application if this is done.

The following conventions are used in the figures showing the syntax ofinput files in this section. Upright text (such as FUNCTION:) mustappear exactly as shown. Italic text (such as object₋₋ name₋₋ 1) denotesinformation that the user must supply. Text in the current text font(Helvetica) is explanatory information and does not appear in the actualfile. Elements of a file that are optional are enclosed in <>.Generally, the order in which elements appear in files is important, andmust be the same as shown here.

All whitespace characters (spaces, tabs, end-of-lines) can be expandedfor clarity. Separation of entry elements by end-of-lines is recommendedto make the file more readable. Comments can be inserted at any point inthe file using the // comment-to-end-of-line format from the C++language. Lastly, all references to timestamps require the followingsyntax:

    "mm/dd/yyyy hh:mm:ss"

This file, identified as filename.sys, contains a list of file names.The file names identify the Blackboard Structure Description File(BSDF), and all knowledge source files, both Rule Based Definition Files(RBDF) and Case Description Files (CDF) for a particular application.For knowledge source files, the form of display can also be definedhere. If the file name is followed by ",NORMAL", then the knowledgesource is allocated a standard size window. If the NORMAL switch isomitted, or if the ICON switch is used, then the knowledge source isonly allocated an icon in the upper left corner of the screen. FIG. 27shows the syntax of the file. Note that all normal UNIX rules for theuse of pathnames in file specifications apply. A valid system file mustinclude exactly one BB file first, followed by a minimum of oneknowledge source file. All rule based knowledge source file names mustprecede case based file names.

Blackboard Structure Description File

The Blackboard Structure Description File (BSDF) contains theinformation necessary to create internal structures used by theblackboard process. The information in the BSDF maps directly into theblackboard structures described herein. A BSDF is identified asfilename.bb. The syntax of the BSDF is shown in FIG. 28.

Every object in the blackboard has a separate entry in the BSDF. Forevery object, all attributes of the object are identified by name. Eachobject must have a unique name. Attribute names are repeated asnecessary. Choices for value types are shown in FIG. 6.

A valid BB file must include a minimum of one object, with a minimum ofone attribute.

Rule Base Description File

The Rule Based Definition File (RBDF) contains the information necessaryto set up a rule based knowledge source. The data in the RBDF mapsdirectly into the rule base structures described herein. A RBDF isidentified as filename.rb. The syntax is shown in FIG. 29.

There are three parts to an RBDF. The EVENTS portion of the RBDF is alist of expressions that are used by the event detector to determine ifincoming data constitutes an event relevant to the rule base. ThePRECONDITIONS portion of the RBDF is also an expression list, which isused by the activation/agenda manager to further determine if aknowledge source should be activated. For the EVENTS and PRECONDITIONSlist of expressions, it is understood that the list is "OR"ed. That is,any of the expressions evaluating to true will indicate to theappropriate process (event detector or activation/agenda manager) thatcertain conditions have been satisfied. If there are no eventexpressions, then that knowledge source will execute only if theprecondition part includes an every operator. If there are noprecondition expressions, then the knowledge source will be activatedwhenever one of its events is true. The "EXPRESSION:" prefix must befollowed by an expression (i.e., it must not be present unless anexpression is present.)

The RULE BASE STRUCTURES portion of the RBDF contains the structuralinformation needed by the rule based knowledge source process. Theprocess starter provides the RBDF name to each of these three processes(i.e., event detector, activation/agenda manager and rule basedknowledge source); it is their responsibility to extract the necessaryinformation. Each section of the RBDF is separated by a string of `*`characters.

The evaluation expressions used for the EVENTS and PRECONDITIONS, aswell as the expressions used in the RULE BASE STRUCTURE part of the RBDFare further discussed herein.

Other comments:

all references to nodes, contexts and piece-wise linears in rules,meta-rules and evaluators must be defined first in the earlier parts ofthe RULE BASE STRUCTURE of the file.

the ***** and ------ lines are required syntax, since they are used bythe parsing software as separators between sections of the file.

a piece-wise linear's XY-LIST must have the X values in ascending order.

at least one context must have the value of 1 (i.e., when the file isloaded, at least one context must be TRUE; meta-rules can change thisduring execution.)

a valid rule base must contain a minimum of one data node, onemalfunction node, one rule, and one context.

Case Description File

The Case Description File (CDF) contains the information necessary toset up a case based knowledge source. The data in the CDF maps directlyinto the case table structure described herein. A CDF is identified asfilename.cb. The syntax is shown in FIG. 30.

The division of the CDF into three portions is similar to that for theRBDF. The EVENTS and PRECONDITIONS portions are identical to those forthe RBDF. The CASE BASE STRUCTURE portion provides the structuresnecessary to set up a case table.

The CASE BASE STRUCTURE consists of two parts:

First, functions (equal, greater and less) are defined. Each function isdefined in terms of two margins, expressed in percentage points. Theywork as follows.

equal function (FEQ): if two numbers are within (equal low₋₋ margin) %of each other, then the score is 1.0; if two numbers are more than(equal₋₋ high₋₋ margin) % different, then the score is 0.0; otherwise, alinear interpolation is performed between the two margins.

greater-than function (FGT): if the current number is greater that thecase history value by more than (greater--.sub. high margin) %, then thescore is 1.0; if the current number is less than the case history valueby more than (greater₋₋ low₋₋ margin) %, then the score is 0.0;otherwise, a linear interpolation is performed between the two margins.

less-than function (FLT): if the current number is less that the casehistory value by more than (less₋₋ high margin) %, then the score is1.0; if the current number is greater than the case history value bymore than (less₋₋ low margin) %, then the score is 0.0; otherwise, alinear interpolation is performed between the two margins.

Second, the cases themselves are defined. Each case must be given aname. Each case in the case table must map into an object attribute inthe blackboard. For each case, a set of object attributes is thenspecified, along with values and weights. The values are given as value,time pairs. Each pair is followed by an optional function name (FEQ,FGT, FLT) and weight. If the latter are omitted, FEQ and W1.0 (weightof 1) are assumed. The match-points-on-curve function, as definedherein, is thus invoked by omitting the function names and weights.

A valid case based knowledge source must have a minimum of one casepoint.

Input Data File

The Input Data File (IDF) contains the sets of data simulating incomingdata to the system. The user interface process reads this file andsupplies the data to the event detector process. An IDF is identified asfilename.dat. The syntax is shown in FIG. 31.

Output Files

Output files are generated by the shell in the course of its operation.

"LOG" Files

LOG files are generated by rule based knowledge sources whose log flaghas been turned on.

The information in these files provides a relatively detailed tracethrough the execution of a rule base.

"OUT" Files

Each knowledge source that generates diagnostics writes to an OUT file.Each entry in OUT files generated by a rule based knowledge sourcerepresents a diagnostic message, with associated priority and severitymeasures. Each entry in OUT files generated by a case based knowledgesource includes the calculated scores for its cases.

Additional information may be included in these files.

"DIA" File

The Diagnostics File (DIAF) contains the results of a session run. It isa list of the diagnoses and case matches that the shell has made duringthe just-completed session run. The diagnoses are the orderedcombination of the diagnoses made by the individual rule based knowledgesources, followed by the ordered combination of case matches found bythe individual case based knowledge sources. Basically, the resultsexisting in the OUT files are merged and sorted by time.

Blackboard Status File

The Blackboard Status File (BSF) is similar to the BSDF in that itcontains the structural information necessary to recreate theblackboard. It also contains a snapshot of all of the data values storedin the blackboard. Using the BSF file, the blackboard can be restored ona subsequent session run. Because of its compatibility with the BSDF, italso is identified as filename.BB. The syntax is the same as the BSDF.

User Interaction

All user interaction with the shell occurs through the user interface.The nominal sequence of interaction with the shell is described inherein. Details for the user interface are described elsewhere in thisdocument.

The domain shell program is designed for operation on theHewlett-Packard 9000, Series 700 family of workstations. The workstationshould run the HP-UX operating system, Version 8.05 or higher. TheHP-VUE visual user environment should also be present. This environmentis layered over a Motif-based X-window system. The domain shell usesxterm windows within this framework.

In order to use the shell, users must create input files to be used bythe system. Therefore, it is helpful to be familiar with the shell'soverall design concept as well as the individual input files' syntax andstructure. Other sections herein contain the overall system designdescription and describe the operation of the components of the domainshell.

The creation of input files must be done prior to the operation of theshell. In order to use the shell, the following files must be created:system file, blackboard structure description file, one rule basedescription file for each rule base, one case description file for eachcase base, and at least one input data file. The uses of these files aredescribed herein. The location of these files is not restricted;however, if they are not located in the same directory as the shellexecutable files then the full pathname of the file must be given in thesystem file.

The application development environment in the Version I softwaremanages the naming and placement of files automatically. The developeronly needs to name the application and the knowledge sources.

System File

The system file contains a list of filenames identifying the blackboardstructure description file, and all rule base and case description filesfor the system. The system file is identified as such by the suffix.sys. The file format is shown in FIG. 27.

Note that the order of files named in the system file is important. Thename of the blackboard structure description file should be specifiedfirst, then all rule base description files, and finally all casedescription files. This is the order that is shown in FIG. 27. Only onefile should be specified per line. All of the files specified in thesystem file should exist or initialization errors will occur.

The shell assumes that the files specified in the system file reside inthe same directory as the shell executable files unless full pathnamesare used in the system file.

There is an option available to determine whether to fully open aknowledge source window or iconify it. The default system operation isto iconify all knowledge source windows. However, if a ,NORMAL is placedat the end of a knowledge source file specification line, then thewindow associated with that knowledge source's process will be fullyopened. This feature is useful for making detailed observations of theoperation of a particular knowledge source. If desired, all knowledgesource windows can be fully opened by using the same ,NORMAL suffix onall knowledge source file specification lines. The default behavior(iconified knowledge sources) can be explicitly specified by using ,ICONat the end of a knowledge source specification line.

Blackboard Structure Description File

The blackboard structure description file (BSDF) contains the definitionof all objects, and all attributes for each object. Objects andattributes are identified by names given by the user. The blackboardfile is identified as such by the suffix .bb. The file format is shownin FIG. 28.

The names of the objects and associated attributes are used in theknowledge source description files, and in the input data files. Namesmust match exactly in spelling and case in order for the shell tooperate properly.

There is no specific maximum history length. Since the blackboard willmaintain data points it receives within this history length, excessmemory will be used and the system will be slowed needlessly if thehistory length is longer than what is required by the knowledge sources.A good check on this is to review the history lengths required byknowledge sources and adjust the blackboard history lengthsappropriately.

Significant data received by the blackboard can be forwarded to the userinterface windows. Under the object's attribute, include the line,DEMON: MMI₋₋ WRITE. When the blackboard receives a new value of thisobject attribute, the object and attribute names and the value will beforwarded to the man machine interface. The value will be shown in theman machine window. This is a powerful tool for working with the shell,since it allows any object attribute to be tracked as the system isrunning. However, if too many object attributes have the DEMON turnedon, the system will be slowed, and the number of values printed in theman machine window will be large. Once an application is tested, the useof the DEMON should be reserved for significant object attributes, suchas those representing malfunctions. This is a feature of only theprototype. The user interface is the proper destination for blackboarddata.

Rule Base Description Files

Each rule base is defined by a description file that is comprised ofthree sections. The first section is a list of event expressions, calledEVENTS. These expressions are used by the event detector to determine ifa knowledge source should be placed on a list of knowledge sources to befired which will be sent to the agenda manager. The second section is alist of event expressions, called PRECONDITIONS. These expressions areused by the agenda manager to check if a knowledge source should befired at a given time.

For the EVENTS section, care should be exercised in writing eventexpressions that depend on the arrival of new data. Each eventexpression should refer to new data arriving from one source only(either the user interface or one of the other knowledge sources). Alldata is sent through the event detector, but each source of data (aknowledge source or the user interface) sends it in separate batches.Therefore, the event detector can only recognize data in a particularbatch as new, even if data arriving from another source has the sametime stamp. In general, caution should be exercised in writing eventexpressions with more that one "new" data point in the expression.

The PRECONDITIONS section contains expressions that are similar to thosein the EVENTS section. Also, a periodic precondition can be set to causea knowledge source to fire at regular intervals. This is done by placinga statement "every n" as a precondition, where n is the intervalduration in seconds.

The third section defines the rule base structure, including allcomponents of rule base such as hypotheses, malfunctions, rules, etc. Arule base description file is identified as such by the suffix .rb.Details of the file format are shown in FIG. 29.

The blackboard structure description file should be referenced andedited as necessary so that all object attributes named in the rule baseas blackboard elements exactly match the names in the blackboard;mismatches will cause the rule base to fail to properly initialize.

There are many operators available in constructing a rule baseddescription file.

Case Description Files

Each case base is defined by a description file that also contains threesections. The first two sections are EVENTS and PRECONDITIONS sectionsas described above. The third section contains the case base itself,consisting of a set of cases with values. A case description file isidentified as such by the suffix .cb. Details of the file format areshown in FIG. 30.

AS for the rule based description files, the object attributes in thecase based files must exactly match blackboard object attributes, or aloading error will occur.

Each case should be comprised of a set of object attributes withassociated case values. The time stamps used for the case values shouldreflect the required time intervals necessary for comparison; theabsolute time is not important. For example, if in a particular case, anobject attribute has a characteristic set of values over a 10 secondperiod, the difference in the time stamps between the most recent andoldest values should be 10 seconds.

Input Data File

This file consists of the data that is to be used by the shell tosimulate the arrival of actual data. The input data file is identifiedas such by the suffix .dat. The file format is shown in FIG. 31.

Input data is expected to be structured so that all data with aparticular time stamp is grouped together in the same data set.

Object attribute names should exactly match the blackboard names. Anerror will be reported when the input data file is scanned if namemismatches occur.

The data in the input data file should appear in chronological order,from earliest data to latest data.

The input data file is intended only for testing purposes, to verifyproper application operation.

Log Files

Each knowledge source that generates diagnostics writes to a Log File(RLOGF or CLOGF), with entries representing a diagnostic message withassociated priority and severity measures. The syntax is shown in FIG.32.

Diagnostic File

The Diagnostic File (DIAF) contains the results of a session run. It isa list of diagnoses with associated confidence factors. The syntax isshown in FIG. 33.

Blackboard Status File

The Blackboard Status File (BSF) is similar to the BSDF in that itcontains information necessary to recreate the blackboard. Using the BSFfile, the blackboard can be restored on a subsequent session run. Thesyntax is shown in FIG. 34.

Use of the Program

The user must be in the directory where the domain shell executablefiles reside. All input files should also be in this directory, unlessfull pathnames are used for files located elsewhere. Also, output filesare written in this directory. The program opens at least five windowsduring execution so it is advisable to have a display with only onewindow currently open. This window can reside anywhere on the display,but it is recommended that it be placed in the lower left corner.

The program is invoked by typing the program's name followed by thesystem file name. As currently installed, the program's name is user₋₋int. This can be changed by the user if desired. However, the names ofthe other executable files should not be changed.

Windows will be opened for each of the domain shell processes:blackboard, event detector, agenda manager, man machine interface, andeach knowledge source. All windows are xterm windows, and can beresized, moved, or iconified. Each window is appropriately titled in thetitle bar--knowledge source windows are identified by their respectivedescription file names. All knowledge source files are initiallyiconified (unless the NORMAL window option was specified in the systemfile), but can be opened as desired by the user. Within a window, theuser can select a variety of viewing and tracing options by placing thepointer within the window, hitting the left or the center mouse buttonwhile holding the Ctrl key down, and choosing the desired option. Ascrollbar for the window can be enabled by hitting Ctrl-Center₋₋ Mouse₋₋Button and choosing the option "Enable Scrollbar".

A window's title bar identifies the process running within it (with theexception of the user interface window, which is a standard terminalwindow that the user has previously opened). The knowledge sources areidentified by the name of the knowledge source description fileassociated with it. When the windows are iconified, the knowledge sourcewindows are still identified by the description file's name; the otherprocesses are identified by two letter abbreviations--bb for blackboard,ed for event detector, am for agenda manager, and mm for man machineinterface.

Most interaction with the user occurs in the first window, where theprogram was started. This window will present the user with a menu oftop level options after the system is set up. There are four choices:Start Data, Continue Data, Set Operating Parameters, and End theSession.

Start Data--Option 1

This option, when chosen by the user, prompts him for the name of aninput data file. It then notifies all knowledge sources to reset andprepare for a session run. After scanning the input data file, theprogram prints the length of time needed to run the data in seconds. Theuser is given the option of compressing the time scale in order tocomplete a data set run in a shorter or longer period of time. Thecompression factor is divided into time intervals extracted from thedata file to determine the compressed interval. After the compressionfactor is set, data is read from the input data file and sent at theappropriate time to the event detector, which forwards it to theblackboard. The system will operate, firing knowledge sources asappropriate, until the input data is exhausted. Informational messageswill appear in the shell windows as the data set run proceeds. When therun is over, the user is presented with the top level menu in the userinterface window.

Evidence of the operation of the blackboard is shown by the use of thecharacters `>` and `<` in the blackboard window. When data is placed inthe blackboard, the `>` character is printed; when data is retrievedfrom the blackboard, the `<` character is printed.

The event detector will print out a set of three `.` characters as itproceeds with the evaluation of event expressions. The agenda managerwill also show a set of three `.` characters indicating the completionof an activity. The man machine interface will print received data inits window as the blackboard sends it. Each data point sent will bedisplayed along with the object and attribute names. Only those object?attributes with DEMON: MMI₋₋ WRITE will be displayed, and only when anew value is received by the blackboard.

If Start Data is chosen again after a data set has been run, then alldata in the blackboard is discarded and all knowledge sources are reset.This, in effect, starts the session over. For continuing a run withfurther data, use Option 2, Continue Data.

Continue Data--Option 2

This option causes the system to run a data set in a manner identical tothat for Option 1--Start Data. However, for the Continue Data option nomessages are sent to knowledge sources to reset, and the blackboard datais retained from the previous run. This allows the rule bases tocontinue operation with current values that were set as a result ofoperations during a previous data set run. As for Option 1, the user isprompted for the name of an input data file. Data in this file should bebegin with a time stamp that is chronologically later than the last datain the previous data set in order for this option to operate correctly.If further data is sent to the blackboard with time stamps earlier thandata from a previous run, the blackboard will place the data in theblackboard as a current value for an attribute with no history. However,for attributes with non-zero history length, the blackboard will insertthe value at someplace in the history other than as the latest value.This will cause indeterminate behavior as the event detector may fire aknowledge source based on the arrival of "new" data; when the knowledgesource retrieves the data from the blackboard, the data is hidden andthe knowledge source fires using possibly incorrect data points.

When the data set is running, the appearance of the shell processes isidentical to that for Option 1--Start Data.

Set Operating Parameters--Option 3

This option allows the user to set parameters for rule bases. If thisoption is chosen, the user is prompted for the name of a rule base. Onlyrule bases have the option of setting operational parameters. The casebased knowledge sources have no Set Parameter options. There are sixchoices for setting parameters: Trace, Log, Step, Breakpoint,Alpha/Beta, and SF/NF.

If Option 3 is selected by the user, he is then prompted to enter thename of a knowledge source file. This specifies the knowledge sourcefile for which the parameter is to be set. Currently, only rule baseshave parameters that can be set. After the knowledge source file isspecified, the user is then prompted to enter the code corresponding tothe parameter to be set.

Trace--Parameter Option 0: If this option is chosen, the user is askedwhether to disable or set a tracing capability. When set, this causesdetailed descriptions to be displayed in the rule base window when eachrule in the rule base is fired.

Log--Parameter Option 1: If this option is chosen, the user is askedwhether to disable or set a logging capability. When set, this causesdescriptions identical to those generated for the Trace option to besent to a file. The file is named with a root name the same as the rulebase description file that created it, with the .log extension.

Step--Parameter Option 2: If this option is chosen, the user is askedwhether to disable or set the step functionality. When set, the Stepoption causes the rule base to stop after each rule is fired; the rulebase will continue only when the user acknowledges the rule firing byresponding in the rule base window. Therefore it is necessary for theuser to change his focus of attention to the rule base window when thisoption is set. When the rule base fires, the processing will stop andthe user will have options within the rule base. Data will continue tobe sent to the blackboard, and all other shell processes will proceed.However, further knowledge source firings will be delayed until the userhas completed stepping through the rules in the rule base. Execution ofthe rest of the shell will therefore be disabled. The purpose of theStep option is to allow the user to follow in detail the sequence ofrule firings in a rule base. Since its use generally ruins the timing ofprocess execution, it should only be used in configurations with onlyone knowledge source, for debugging purposes.

Breakpoint--Parameter Option 3: If this option is chosen, the user canset or remove breakpoints at rules in a rule base window. In order touse this option, the user must move to the appropriate rule base windowin order to set the breakpoints. In the rule base window, the user canset and remove breakpoints for any rule in the rule base. Uponcompletion, the user must return to the first window to choose a toplevel option.

AS with the Step option, rule base operation is suspended during firingif breakpoints are set. The use of breakpoints is for observation ofrule base operation, rather than shell performance as a whole. In otherwords, it should only be used in configurations with only one knowledgesource, for debugging purposes.

Alpha/Beta--Parameter Option 4: If this option is chosen, global valuesfor alpha and beta cutoffs can be set for a particular rule base. Theuser is prompted to enter values for alpha and beta (from -1.0 to +1.0).These values are then passed to the rule base specified.

SF/NF--Parameter Option 5: If this option is chosen, global values forthe sufficiency and necessity factors (SF and NF) for rules can be setfor a particular rule base. The user is prompted to enter values for SFand NF (from -1.0 to +1.0). These values are then passed to the rulebase specified.

End the Session--Option 4: If this option is chosen, the session isended and the program exits. Output files are written as describedelsewhere. Each knowledge source generated a log file that contains alist of diagnoses. The blackboard writes an output file that containsthe structural information from the blackboard input file, and asnapshot of all data values currently stored in the blackboard.

Output Files

When the session is ended, each of the knowledge sources prints out atleast one output file that contains the results of operation. A rulebase may print out a log file if that parameter has been set through theset parameter option.

Each time a session has ended after a set of data has been run, everyrule base for the system will create an output file with the results ofdiagnosis. This file has the same root filename as the rule basedescription file, but with the suffix .out. The results of diagnosticsgenerated each time the rule base was fired are written into this file.The data written includes the diagnoses that are reached, the number ofrules that were fired, and the number of rules fired per second.

If the LOG option has been selected for the rule base, then an outputlog file is created. This file has the same root filename as the rulebase description file, but with the suffix .log. This contains detailedmessages that indicate the sequence of operation of the rule base.

The case based processes will write out the results of scoring casesinto a file with the same root name as the case description filename'sroot, and with the suffix .out. The file will contain a record of theresults of scoring over a complete data set run.

The blackboard produces an output file that contains all of the objectand attribute information from the input file plus all of the datacurrently stored in the blackboard. This file can be used as an inputfile for subsequent session runs. In this case, input data sets shouldcontain time stamps chronologically later than the latest data in theblackboard, or indeterminate behavior will result.

Errors

Errors encountered in using the shell can generally be divided into twocategories: syntax/loading errors and logical errors. If a particularknowledge source encounters an error, it will print an error messageidentifying the line number in the file where the error is located. Anerror message is sent to the user interface. This causes the userinterface to try to kill the shell processes and exit.

Logical errors are causes when the information contained in theknowledge source files does not correspond to the desired performancedue to incorrect rules, etc. These errors may be difficult to locate.The shell provides several tools to assist in following the operation ofthe individual shell processes. These include the Set Parameter Optionsfor the rule bases. Also, the values of object attributes posted on theblackboard can be printed in the man machine window using the DEMONfeature. All of the output files can be used to assist in discoveringthe error.

Control Module

The control module is responsible for coordinating the activities ofvarious parts of the shell. Its design is intended to allow theapplication developer to specify control actions that may lead toapplications that exhibit the following characteristics:

speed: the ability to execute a task in a short period of time, and withminimum control overhead responsiveness: the ability to react to changedconditions when the reaction is required timeliness: the ability toreach conclusions (diagnoses, or partial diagnoses) by the time they areneeded adaptability: the ability to change strategy as conditionschange.

Note that these characteristics are not inherently built into thecontrol module software; rather it is the application developer'sresponsibility to make judicious use of the features of the controlmodule and thereby accomplish the desired results.

Speed depends strongly on the individual performance characteristic ofeach knowledge source. The control module contributes overhead. It isobviously desirable to maintain a small control overhead time toknowledge source execution time ratio. One way to do this is to minimizeoverhead, but this is only possible up to a point. Increasing the grainsize of the knowledge sources is another way. Unfortunately, largegrained knowledge sources tend to be unresponsive. Thus knowledgesources are interruptible.

Interruptibility is also useful for adaptability. Since this blackboardarchitecture is essentially event driven, it is possible thatasynchronous events can change the execution environment (context) to anextent that the currently executing knowledge source is irrelevant oreven inappropriate. The control module can then abnormally stop thecurrent knowledge source and start executing other knowledge sources.

An aspect of interruptibility appears when asynchronous events changethe context such that the currently executing knowledge source issuperseded in importance by other knowledge sources. This situation isresolved by the use of priority levels associated with each knowledgesource. A knowledge source which was interrupted because of higherpriority tasks can be defined to be resumable.

The fundamental aspect of the control mechanism of the shell is that itis strictly condition driven. It has two modes of operation:

1. Data driven: the conditions that trigger the execution of theknowledge sources are the asynchronous receiving of data. This data canbe from outside the system (usually from on-line sensors), or it can bethe results of executing another knowledge source. Usually, it is notjust the receiving of data that defines a triggering condition, butrather that the received data satisfy more specific conditions, such asleaving a pre-defined normal range.

2. End-user requested: the condition that leads to the execution of aspecific knowledge source is caused by an end-user request. This wouldusually happen if high quality triggering conditions are not known, andthus a knowledge source should execute strictly under end-user control,or if the condition definitions are incomplete, and the end-usersuspects that a specific knowledge source can contribute to the on-goingdiagnostic process.

The control mechanism needs the following information in order tooperate:

1. A set of conditions that cause a process (knowledge source, orexternal) to execute. For performance reasons, the triggering conditionsare divided in two groups: events and preconditions. The differencebetween them is artificial, and it is the application developer'sresponsibility to divide the conditions among the two groups in such away that the performance is optimal.

2. Each process (knowledge source, or external) must be characterized asinterruptible or not. Each interruptible process must have a prioritylevel.

3. Each interruptible process (knowledge source, or external) may have aset of refire conditions defined, which will allow the control mechanismto determine if an interrupted knowledge source should be reactivated orterminated upon completion of the interrupting action.

4. Each process can time-out or not. For those processes that cantime-out, a running time must be specified, at the expiration of which,the process is suspended, terminated, or continued.

The checking of conditions can be thought of in terms of a rule baseparadigm:

IF condition-is-true THEN perform-action The conditions on the left handside of control rules are represented in terms of expressions,consisting of operands, which are data points (expressed as blackboardobject/attributes) and operators, described in Appendix A.

The only right hand side action is to activate a process, which can be aknowledge source, or an external process.

The control mechanism consists of the continuous repetition severalsteps:

1. Event detection: all data going to the blackboard passes through theevent detector module. Every time a data packet is received by the eventdetector, it evaluates the truth of the event preconditions that involveinformation in the packet. For each true condition, the correspondingprocess activation request is passed on to the next step.

2. Activation: the requests received from step 1 are processed by theactivation manager module. For each knowledge source or external processactivation request, its preconditions are evaluated. Those found to betrue are also passed on to the next step.

3. Scheduling: the requests from step 2 are received by the agendamanager. This module keeps track of the currently executing module, andit schedules the new requests according to priority levels. This mayrequire the suspension of the current activity. This module alsodetermines if a suspended task should be resumed (refired) or not, andif a running task should be timed-out or not.

As stated earlier, the control mechanism is largely applicationspecific. While the architecture described above is quite general innature, the tasks carried out by the various modules may containnumerous elements that are application specific. As always in this typeof situation, an approach that uses a mix of procedural (controlactions) and declarative (control rules) methods should be implementedin the future.

The control module is responsible for coordinating the activities of theshell for the purpose of diagnosing occurring or impending malfunctions.It is the repository of the problem solving strategy needed toaccomplish an application's goals. Since different problems requiredifferent strategies, the control module will be largely applicationspecific. Nevertheless, given common characteristics of the real-timeplant diagnostic domain, several functional requirements can bedescribed and implemented.

General Requirements

The real-time nature of the shell is reflected in the following controlmodule requirements:

speed is the ability to execute a task in a short period of time, andwith minimum control overhead

responsiveness is the ability to react to changed conditions when thereaction is required

timeliness is the ability to reach conclusions (diagnoses, or partialdiagnoses) by the time they are needed

adaptability is the ability to change strategy as conditions change.

General Characteristics

Speed depends strongly on the individual performance characteristic ofeach knowledge source. The control module contributes overhead. It isobviously desirable to maintain a small control overhead time toknowledge source execution time ratio. One way to do this is to minimizeoverhead, but this is only possible up to a point. Increasing the grainsize of the knowledge sources is another way. Unfortunately, largegrained knowledge sources tend to be unresponsive. This leads to one ofthe fundamental required characteristics for this system: largeknowledge sources should be interruptible.

Interruptibility is also necessary for the adaptability requirement.Since blackboard architectures use essentially event driven mechanisms,it is possible that asynchronous events can change the executionenvironment (context) to an extent that the currently executingknowledge source is irrelevant or even inappropriate. The control moduleshould be able to abnormally stop the current knowledge source and givecontrol to other knowledge sources.

An aspect of interruptibility appears when asynchronous events changethe context such that the currently executing knowledge source issuperseded in importance by other knowledge sources. This situationintroduces another fundamental required characteristic of this system:knowledge sources should be prioritized. Finally, a knowledge sourcewhich was interrupted because of higher priority tasks, may or may notbe resumable.

These characteristics can be summed up in one expression: dynamic focusof attention.

Events

The fundamental aspect of the control mechanism is that it is strictlyevent driven. It has two modes of operation:

1. Under normal conditions, it is purely on-line, sensor data driven.The events that trigger the execution of the knowledge sources aresimply the receiving of sensor data. The main characteristic of thismode is that no malfunctions are detected, i.e., everything is "normal",and no interaction is required with the end user. The control modulebasically allows the knowledge sources to execute in sequential fashion,without interruption, until . . .

2 . . . asynchronous events take place which require immediateattention. Such events can be on-line generated, by sensor valuesleaving pre-defined normal ranges, or they can be the result ofexecuting a knowledge source, or they can be end user generated, byspecific requests for focus of attention. There may be yet other ways togenerate events.

A special type of event is expiration of time. The system clock tick isa periodic data point.

Control Architecture

Blackboard control mechanisms generally consist of the continuousrepetition of a four step cycle:

trigger

precondition check

schedule, and

execute

The block diagram in FIG. 35 shows an approach that closely matchesthese steps, while also showing some differences. Each module isdescribed next.

The communications manager/event detector is similar, but not identicalto the trigger mechanism found in common blackboard control. It performsthe dual role of carrying out communications with sources of data, anddetermining if the incoming data forms an event. Data may originateexternal to the system, in which case the communications managerreceives it from the I/O interfaces (discussed in the InterfaceRequirements section), or from local sources (knowledge sources, theuser interface, or the system clock). In any case, once the data isreceived, it is written on the blackboard, if appropriate, and testedfor event generation. The results of this last step are passed on to thenext module.

The activation manager plays the role of the precondition check. In manyapplications of blackboard architectures this is a rather time consumingtask, generating high overhead. A simple approach is used in accordancewith the present invention and is necessary for improved systemperformance. A two-step method of the present invention includes: firstuse look-up tables to find the knowledge source(s) affected by theincoming event, and extract (from the table) its self-selectingprecondition; second execute the precondition. If true, determine thetask's priority and place the KSAR (Knowledge Source ActivationRequest/Record) onto the next module's agenda.

The agenda manager is the basic scheduler, but it does more than justschedule the next knowledge source to execute: it also determines if thecurrently executing knowledge source should be interrupted (if it isinterruptible), determines if it is resumable, in which case it is onlysuspended (and rescheduled for continuation), etc. Note that this moduleis not a full-blown agenda-based multi-tasking controller, but rather itonly implements the specific required characteristics for this domainshell, as discussed here.

Implementation

As stated earlier, the control mechanism is largely applicationspecific. While the architecture described above is quite general innature, the tasks carried out by the various modules may containnumerous elements that are application specific. As always in this typeof situations, an approach that uses a mix of procedural and declarativemethods is most appropriate.

In particular, the event detector is highly specific to eachapplication. A declarative syntax (rules) could be used to allow theapplication developer to tailor this module to each application. Typicalexamples of declarative descriptions are "whenever" and "every <timeinterval>" rules. On the other hand, a procedural component willinevitably be needed and has to be taken into account. The other twomodules, the activation and the agenda managers, are purely procedural,since the approach described in the previous section is believed toapply across all applications in the domain considered here.

Another implementation aspect is related to the partitioning of themodules shown in FIG. 35 into executable processes. Since incoming dataarrives asynchronously, the communications manager/event detector modulemust form a process by itself. The other two modules could form oneprocess, activated by the detection of an event. The execution of aknowledge source obviously forms a separate process.

The event detector module of the control module includes data structureswhich receive all data inputted to the blackboard from various sources.The data structures are arranged to analyze the data and determinewhether any knowledge source execution preconditions are met. In otherwords, the data structures look at the data and determine which if anyknowledge sources operate on that data. An algorithm implemented by thedata structures maps data as it is received such that only the knowledgesource which acts on the specific data received is subsequently checkedto see if it is available for execution. The activation/agenda moduledoes this checking in accordance with the predetermined knowledge sourcepriority scheme. Therefore, significant time is saved in that onlyknowledge sources which operate on the specific data received arechecked by the control module for execution availability. Thus, in asystem having a plurality of knowledge sources acting on different datapoints, significant time is saved with the algorithm of the presentinvention.

As used herein, "interruptibility/priority scheme" includes a controlscheme which prioritizes execution of the knowledge sources and providesfor the interrupting execution of a lower priority knowledge source infavor of executing a higher priority knowledge source.

In addition, the control process of the present invention (including theevent detector module and the activation/agenda manager module) controlsoperation of the knowledge sources in accordance with a knowledge sourceinterruptibility/priority scheme. Execution of certain knowledge sourcescan be interrupted in favor of higher priority knowledge sources whoseexecution preconditions have been met. When an execution knowledgesource is interrupted and a higher priority knowledge source isexecuted, thereafter the control process determines whether to reinstateexecution of the interrupted knowledge source. Also, knowledge sourceswhose execution preconditions are met and have not yet executed arequeued for execution in order of priority. In this manner, a knowledgesource interruptibility/priority scheme is implemented.

Having now described a limited number of embodiments of the invention,it should now be apparent to those skilled in the art that numerousother embodiments and modifications thereof are contemplated as fallingwithin the scope of the present invention as defined by the appendedclaims.

What is claimed is:
 1. An artificial intelligence software shell forplant operation simulation comprising:a blackboard module including adatabase having objects representing plant elements and concepts; atleast one knowledge source module including an artificial intelligenceoperation scheme, in communication with the blackboard module, operatingon specific predefined blackboard objects; an input data module, incommunication with the blackboard module and the at least one knowledgesource module, enabling data to be inputted to the shell; and a controlmodule, in communication with the input data module and the at least oneknowledge source module, receiving all input data and controllingoperation of the at least one knowledge source in accordance with apredetermined knowledge source interruptibility/priority scheme; whereinthe control module includes an event detector module, in communicationwith the input data module, receiving all input data and determiningwhen the at least one knowledge source module should execute, the eventdetector module having a hash table defined by a chaining algorithm. 2.A software shell as claimed in claim 1 wherein the control moduleincludes:an activation/agenda manager module, in communication with theat least one knowledge source module and the event detector module,executing the at least one knowledge source module in accordance withthe predetermined knowledge source interruptibility/priority scheme. 3.A software shell as claimed in claim 2 wherein the at least oneknowledge source module includes:a rule-based knowledge source modulehaving a forward-chaining belief propagation scheme including rules inif-then-else form with associated levels of belief; and a case-basedknowledge source module having a data comparison scheme includingpredefined patterns and conditions, whereupon execution of thecase-based knowledge source, the conditions are inferred to be true if acertain level of closeness is found between received data and thepatterns.
 4. A software shell as claimed in claim 3 wherein the at leastone knowledge source module includes a plurality of knowledge sourcemodules having varying levels of priority.
 5. A software shell asclaimed in claim 3 wherein each of said modules includes a softwareprocess.
 6. A software shell as claimed in claim 3 wherein theblackboard module database includes a hierarchy of objects havingvertical hierarchical connections and horizontal links.
 7. A softwareshell as claimed in claim 6 wherein each blackboard object hasattributes and each attribute has at least one value, the databaseincluding a hash table and plurality of pointers for linking the objectsand corresponding attributes and values.
 8. A software shell as claimedin claim 7 wherein the event detector module further includes:the hashtable having entries for each input data source; a data point structureincluding entries for objects and corresponding attributes and values,the entries of the hash table pointing to entries in the data pointstructure; an indirect expression list pointed to by the data pointstructure; and an expression list, pointed to by the indirect expressionlist including entries for knowledge source previous and updated values.9. A software shell as claimed in claim 8 wherein the event detectormodule further includes a message evaluator, receiving messages relatedto input data, checking the messages for syntax errors and implementingthe hash table algorithm if no syntax error is found.
 10. A softwareshell as claimed in claim 9 wherein the activation/agenda manager modulefurther includes:a FIFO queue for activation of event driven knowledgesources; a time-based queue for periodic knowledge sources; and aknowledge source/precondition expression structure for checkingknowledge source execution preconditions.
 11. A software shell asclaimed in claim 10 wherein the activation/agenda manager module furtherincludes:an array having objects and corresponding attributes andvalues; and an expression list including each knowledge source pointedto by the array.
 12. A software shell as claimed in claim 6 wherein thevertical hierarchical connections include IS-A and PART-OF hierarchicalconnections.
 13. A software shell as claimed in claim 2 wherein theactivation/agenda manager module includes a mechanism for interruptingexecution of a knowledge source and executing a higher priorityknowledge source in accordance with the knowledge sourceinterruptibility/priority scheme.
 14. A software shell as claimed inclaim 13 wherein the activation/agenda manager module includes amechanism for determining whether an interrupted knowledge source shouldbe rescheduled for execution.
 15. A software shell as claimed in claim 2wherein the event detector module includes a data structure implementingan algorithm such that when data is received, only a knowledge sourcewhich operates on the received data is checked for executionavailability.
 16. A software shell as claimed in claim 1 wherein the atleast one knowledge source module includes:a rule-based knowledge sourcemodule having a forward-chaining belief propagation scheme includingrules in if-then-else form with associated levels of belief; and acase-based knowledge source module having a data comparison schemeincluding predefined patterns and conditions, whereupon execution of thecase-based knowledge source, the conditions are inferred to be true if acertain level of closeness is found between received data and thepatterns.
 17. A software shell as claimed in claim 16 furtherincluding:a blackboard structure description file including object namesand attribute/value pairs for each object; a rule-based description fileincluding rules forming the rule-based knowledge source and adescription of execution preconditions for the rule-based knowledgesource; and a case-based description file including cases forming thecase-based knowledge source and a description of execution preconditionsfor the case-based knowledge source; wherein the blackboard structuredescription file, rule-based description file, case-based descriptionfile, and input data file are user created.
 18. A software shell asclaimed in claim 17 further including:a diagnostics file, created by theshell for each input data file cycle completed, including diagnoses madeby the rule-based knowledge source and case matches found by thecase-based knowledge source; and a blackboard status file, created bythe shell, including blackboard information as modified by any knowledgesources after completion of each input data file cycle.
 19. A softwareshell as claimed in claim 1 wherein the blackboard module databaseincludes a hierarchy of objects having vertical hierarchical connectionsand horizontal links.
 20. A software shell as claimed in claim 19wherein each blackboard object has attributes and each attribute has atleast one value, the database including a hash table and plurality ofpointers for linking the objects and corresponding attributes andvalues.
 21. A software shell as claimed in claim 19 wherein the verticalhierarchical connections include IS-A and PART-OF hierarchicalconnections.
 22. An artificial intelligence software shell for plantoperation simulation comprising:means for storing objects representingplant elements and concepts; at least one knowledge source moduleincluding and artificial intelligence operation scheme, in communicationwith the means for storing, operating on specific predefined objects;means, in communication the means for storing and the at least oneknowledge source module, for enabling data to be inputted to the shell;and means, in communication the means for enabling and the at least oneknowledge source module, for receiving all input data and controllingoperation of the at least one knowledge source module in accordance witha predetermined knowledge source interruptibility/priority scheme;wherein the means for receiving and controlling includes:means, incommunication with the means for enabling, for determining when the atleast one knowledge source module should execute, the means fordetermining including a hash table defined by a chaining algorithm. 23.A software shell as claimed in claim 22 wherein the means for receivingand controlling includes:means, in communication with the at least oneknowledge source module and the means for determining, for executing theat least one knowledge source module in accordance with thepredetermined knowledge source interruptibility/priority scheme.
 24. Asoftware shell as claimed in claim 23 wherein the at least one knowledgesource module includes:a rule-based knowledge source module having aforward-chaining belief propagation scheme including rules inif-then-else form with associated levels of belief; and a case-basedknowledge source module having a data comparison scheme includingpredefined patterns and conditions, whereupon execution of thecase-based knowledge source, the conditions are inferred to be true if acertain level of closeness is found between received data and thepatterns.
 25. A software shell as claimed in claim 24 wherein the meansfor storing includes a database having a hierarchy of objects havingvertical hierarchical connections and horizontal links.
 26. A softwareshell as claimed in claim 25 wherein each object has attributes and eachattribute has at least one value, the database including a hash tableand a plurality of pointers for linking the objects and correspondingattributes and values.
 27. A software shell as claimed in claim 26wherein the means for executing includes means for interruptingexecution of a lower priority knowledge source and executing a higherpriority knowledge source in accordance with the knowledge sourceinterruptibility/priority scheme.
 28. A software shell as claimed inclaim 27 wherein the means for determining includes means for receivinginput data, determining when knowledge source execution preconditionsare met, and checking only a knowledge source whose executionpreconditions are met for execution availability.
 29. A software shellas claimed in claim 28 further including:a blackboard structuredescription file including object names and attribute/value pairs foreach object; a rule-based description file including rules forming therule-based knowledge source and a description of execution preconditionsfor the rule-based knowledge source; and a case-based description fileincluding cases forming the case-based knowledge source and adescription of execution preconditions for the case-based knowledgesource; wherein the blackboard structure description file, rule-baseddescription file, case-based description file, and input data file areuser created.
 30. A software shell as claimed in claim 29 furtherincluding:a diagnostics file, created by the shell for each input datafile cycle completed, including diagnoses made by the rule-basedknowledge source and case matches found by the case-based knowledgesource; and a blackboard status file, created by the shell, includingblackboard information as modified by any knowledge sources aftercompletion of each input data file cycle.
 31. A software shell asclaimed in claim 30 further including stream sockets forintercommunication, the sockets communicating messages in the form of arequest-response pair.
 32. A method of simulating plant operation withan artificial intelligence software shell comprising the stepsof:storing, in a database, objects representing plant elements andconcepts; reading input data from an input data source; determining,from the input data read, when artificial intelligence knowledge sourcesshould execute in accordance with a predetermined knowledge sourcepriority scheme; and executing knowledge sources, in accordance with thedetermination, on specific predefined objects; wherein the step ofdetermining includes the step of implementing a hash table chainingalgorithm.
 33. A method as claimed in claim 32 wherein the step ofexecuting knowledge sources includes the step of updating object values.34. A method as claimed in claim 33 wherein the step of executingknowledge sources includes the steps of:executing rule-based knowledgesources having a forward-chaining belief propagation scheme includingrules in if-then-else form with associated levels of belief; andexecuting case-based knowledge sources having a data comparison schemeincluding predefined patterns and conditions.
 35. A method as claimed inclaim 34 wherein the step of executing case-based knowledge sourcesincludes the step of inferring to be true the conditions if a certainlevel of closeness is found between received data and the patterns. 36.A method as claimed in claim 35 wherein the step of storing includes thestep of storing objects, attributes and values, each object having anattribute and each attribute having at least one value.
 37. A method asclaimed in claim 36 wherein the step of executing knowledge sourcesincludes the step of interrupting execution of a lower priorityknowledge source and executing a higher priority knowledge source inaccordance with a knowledge source interruptibility/priority scheme. 38.A method as claimed in claim 37 wherein the step of executing knowledgesources further includes the step of, after the step of interrupting,determining whether an interrupted knowledge source should berescheduled for execution.
 39. A method as claimed in claim 38 whereinthe step of executing knowledge sources further includes the step of,after determining whether an interrupted knowledge source should berescheduled for execution, rescheduling that knowledge source inaccordance with the determination.
 40. A method as claimed in claim 33wherein the step of determining includes the steps of determining whenknowledge source execution preconditions are met and checking only aknowledge source whose execution preconditions are met for executionavailability.
 41. A method as claimed in claim 39 wherein the step ofdetermining includes the steps of determining when knowledge sourceexecution preconditions are met and checking only a knowledge sourcewhose execution preconditions are met for execution availability.
 42. Amethod as claimed in claim 40 further including the steps of:generatinga blackboard structure description file including object names andattribute/value pairs for each object; generating a rule-baseddescription file including rules forming the rule-based knowledge sourceand execution preconditions; generating a case-based description fileincluding cases and a description of execution preconditions; andgenerating an input data file including a linked list with sets of dataand corresponding time tags simulating input data for running diagnosticcycles.
 43. A method as claimed in claim 42 further including the stepsof:generating a diagnostics file including diagnoses made by therule-based knowledge sources and case matches found by the case-basedknowledge sources; and generating a blackboard status file includingblackboard information as modified by any knowledge sources duringexecution.
 44. A method as claimed in claim 33 further including thesteps of communicating messages through sockets between modules in theform of request-response pairs.
 45. A method as claimed in claim 33wherein the step of executing knowledge sources further includes thestep of executing model-based knowledge sources having interconnectedmodules with simulation relationships and inference relationships.
 46. Acontrol module for an artificial intelligence software shell for plantoperation simulation, the shell including a blackboard module databasehaving objects representing plant elements and concepts, and at leastone knowledge source module including an artificial intelligenceoperation scheme for execution on the blackboard objects, the controlmodule comprising:an event detector module, in communication with theblackboard module, receiving all input data and determining when the atleast one knowledge source module should execute; and anactivation/agenda manager module, in communication with the at least oneknowledge source module and the event detector module, executing the atleast one knowledge source module in accordance with a predeterminedknowledge source interruptibility/priority scheme; wherein the eventdetector module includes a hash table defined by a chaining algorithm.47. An artificial intelligence software shell for plant operationsimulation comprising:a blackboard module including a database havingobjects representing plant elements and concepts; at least one knowledgesource module including an artificial intelligence operation scheme, incommunication with the blackboard module, operating on specificpredefined blackboard objects; an input data module, in communicationwith the blackboard module and the at least one knowledge source module,enabling data to be inputted to the shell; and a control module, incommunication with the input data module and the at least one knowledgesource module, receiving all input data and controlling operation of theat least one knowledge source in accordance with a predeterminedknowledge source interruptibility/priority scheme, the control moduleincludes a hash table defined by a chaining algorithm.
 48. An eventdetector module for an artificial intelligence software shell for plantoperation simulation, the shell including a blackboard module databasehaving objects representing plant elements and concepts, and at leastone knowledge source module including an artificial intelligenceoperation scheme for execution on the blackboard objects, the eventdetector module comprising:a communication module receiving input data;and a determination module, including a hash table defined by a chainingalgorithm, for determining when the at least one knowledge source moduleshould execute.